The digital communication of data, e.g., video and audio data, continues to grow in importance as digital video and audio systems become ever more common. In order to properly decode an encoded bitstream, it is necessary to perform a synchronization function so that individual data packets and/or symbols included in the encoded bitstream can be properly identified and decoded.
MPEG 2 defines one standard for a data packet structure which is intended for transmitting, e.g., audio and video data. The MPEG 2 standard is described in the International Standards Organization--Moving Picture Experts Group, Recommendation H. 222.0, ISO/IEC 13818-1 "Information Technology--Generic Coding of Moving Pictures and Associated Audio" dated Nov. 13, 1994. The MPEG format defines a 188 byte (1504 bit) packet having the structure illustrated in FIG. 1. Note that an MPEG transport packet includes a sync byte having the value 47 HEX at the start of each transport packet. The sync byte is followed by a 3 byte header and a 184 byte payload. The first byte of the data packet, the synchronizing byte, is used as a synchronizing mechanism to allow for the recovery of the packet alignment in a transport bitstream. Packet alignment is normally achieved by detecting the repeating occurrence and position in the bitstream of the sync byte which is assigned the value 47 Hex.
In addition to packet synchronization, the detection and correction of errors in transmitted data is also important if the transmitted data is to be accurately decoded and used, e.g., displayed.
In order to facilitate error detection and correction in transmitted data, cyclic redundancy codes (CRCs) are frequently generated prior to transmission and added to, or incorporated into, a bitstream which is being transmitted. CRC codes, e.g., in the form of one or more CRC check bytes, can be used to identify and correct data errors. Such data errors may be introduced, e.g., during data transmission. Before a CRC code can be used to identify or correct a data error, bitstream synchronization must normally take place. Unless synchronization occurs, the bits corresponding to the CRC code can not be accurately identified and applied to the received data.
One particular standard which is based on MPEG is the multi-media cable network system (MCNS) standard described in the MCNS Data-Over-Cable Interface Specifications, Radio Frequency Interface Specification, Document No. SP-RFII01-970326, Interim Specification (1997). The MCNS standard describes a packet format intended to be used when cable television systems transmit, e.g., video and audio data. While the MCNS standard uses the MPEG transport stream format for the header and payload portion of a packet, rather than use the MPEG defined sync byte for packet alignment, the MCNS standard defines a CRC check byte which is used for both packet synchronization and alignment purposes. In the MCNS standard, the CRC check byte is calculated over the header and payload portion of a packet and then inserted as the first byte of the next packet, e.g., in the position where the MPEG sync byte would be located in the next packet of an MPEG transport stream. FIG. 2 illustrates the bytes used in generating a CRC byte for a transport packet and the placement within a packet stream of the generated CRC byte. At decoding time, processing of the bits of an MCNS transport packet by a syndrome decoder will result in a CRC syndrome which has as its output, the value 47 HEX, assuming correct packet alignment and error free transmission of the packet.
FIG. 3 illustrates a known encoder circuit 300 for generating an MCNS CRC byte. As illustrated, the encoder circuit 300 includes a plurality of 30 unit delay elements 302-331, nineteen summers 340-359, two switches 370, 371 and one delay element 380. The delay element 380 delays the signal input thereto by 1497 clock cycles. The various elements of the encoder 300 are coupled together as illustrated in FIG. 3. During the receipt of the first 1496 bits of input, the switches 370, 371 are in position "A" and, for the next 8 bits are switched to position "B" before being returned to position "A" at the start of the next data packet to be processed. The eight bits of the generated MCNS check byte are obtained from encoder checksum outputs b0 through b7.
A known apparatus 400 for performing a CRC MCNS check byte syndrome decoding operation is illustrated in FIG. 4. As illustrated, the known decoder includes 15 unit delay elements (402-416), 8 summers (420-427). The delay element 480 delays the signal input thereto by 1497 clock cycles. The various elements of the decoder 400 are coupled together to form the illustrated linear feedback shift register (LFSR) arrangement. The operation of the decoder 400 can be described in terms of two functions g(X) and b(X) as follows: EQU f(X)=1+X.sup.1497 b(X)!/g(X)
where EQU g(X)=1+X+X.sup.5 +X.sup.6 +X.sup.8 EQU and b(X)=1+X+X.sup.3 +X.sup.7.
The output of the decoder 400 is the CRC syndrome. After all 1504 bits of the packet plus checksum have passed through the shift register arrangement of the decoder 400, the last 8 bits representing the CRC syndrome should contain the value 47 HEX. Any other value indicates that either the syndrome generator is not correctly aligned to the packet structure, or that an error occurred in the packet. Thus, the repeated generation of the value 47 HEX at the packet interval indicates proper packet alignment.
As described above, the MCNS specification uses a combined sync recovery and CRC polynomial check function. This combined function serves the dual purpose of allowing for the recovery of the packet and byte alignment to restore the transmitted data to an MPEG bitstream, while also performing an error detection operation on each received packet.
As discussed above the MCNS check byte can be used to check for the presence of errors in a received packet corresponding to a particular CRC check byte. As illustrated in FIG. 2, the MCNS check byte for a given packet is positioned in a bitstream following the packet. Accordingly, the CRC calculation used to check a packet for errors is only completed after the complete packet is received. The completion of the CRC calculation using known techniques, requires the use of a delay element capable of delaying the input by 1497 cycles which corresponds to a 1497 bit delay.
It is highly desirable that packets including errors not be used in processing operations which follow the packet synchronization and CRC operations. Thus, it is highly desirable that the error state of a packet be indicated (known) at the start, as opposed to the end, of a packet.
It is also desirable that the CRC function and any operation used to place packet error information at the start of a received packet be capable of being implemented using a minimal amount of storage capability, e.g., flip-flop delay elements and/or memory capacity, in order to reduce costs.
Accordingly, there is a need for methods and apparatus for implementing, in a cost efficient manner, packet synchronization and CRC error checking operations on a bitstream of packets, such as an MCNS packet stream, where a CRC check byte for a transmitted packet is positioned in the bitstream following the corresponding packet header and data. There is also a need for methods and apparatus which allow for the converting of such a bitstream into an MPEG transport packet stream, wherein a sync byte having a value 47 Hex is located at the start of a packet, assuming the packet is error free and/or for indicating an erred packet condition at the beginning of a packet.